As is known, and referring now to FIG. 1, digital rights management (DRM) and enforcement system is highly desirable in connection with digital content 12 such as digital audio, digital video, digital text, digital data, digital multimedia, etc., where such digital content 12 is to be distributed to users. Upon being received by the user, such user renders or ‘plays’ the digital content with the aid of an appropriate rendering device such as a media player on a personal computer 14 or the like.
Typically, a content owner distributing such digital content 12 wishes to restrict what the user can do with such distributed digital content 12. For example, the content owner may wish to restrict the user from copying and redistributing such content 12 to a second user, or may wish to allow distributed digital content 12 to be played only a limited number of times, only for a certain total time, only on a certain type of machine, only on a certain type of media player, only by a certain type of user, etc.
However, after distribution has occurred, such content owner has very little if any control over the digital content 12. A DRM system 10, then, allows the controlled rendering or playing of arbitrary forms of digital content 12, where such control is flexible and definable by the content owner of such digital content. Typically, content 12 is distributed to the user in the form of a package 13 by way of any appropriate distribution channel. The digital content package 13 as distributed may include the digital content 12 encrypted with a symmetric encryption/decryption key (KD), (i.e., (KD(CONTENT))), as well as other information identifying the content, how to acquire a license for such content, etc.
The trust-based DRM system 10 allows an owner of digital content 12 to specify license rules that must be satisfied before such digital content 12 is allowed to be rendered on a user's computing device 14. Such license rules can include the aforementioned temporal requirement, and may be embodied within a digital license 16 that the user/user's computing device 14 (hereinafter, such terms are interchangeable unless circumstances require otherwise) must obtain from the content owner or an agent thereof. Such license 16 also includes the decryption key (KD) for decrypting the digital content, perhaps encrypted according to a key decryptable by the user's computing device.
The content owner for a piece of digital content 12 must trust that the user's computing device 14 will abide by the rules and requirements specified by such content owner in the license 16, i.e. that the digital content 12 will not be rendered unless the rules and requirements within the license 16 are satisfied. Preferably, then, the user's computing device 14 is provided with a trusted component or mechanism 18 that will not render the digital content 12 except according to the license rules embodied in the license 16 associated with the digital content 12 and obtained by the user.
The trusted component 18 typically has a license evaluator 20 that determines whether the license 16 is valid, reviews the license rules and requirements in such valid license 16, and determines based on the reviewed license rules and requirements whether the requesting user has the right to render the requested digital content 12 in the manner sought, among other things. As should be understood, the license evaluator 20 is trusted in the DRM system 10 to carry out the wishes of the owner of the digital content 12 according to the rules and requirements in the license 16, and the user should not be able to easily alter such trusted element for any purpose, nefarious or otherwise.
As should be understood, the rules and requirements in the license 16 can specify whether the user has rights to render the digital content 12 based on any of several factors, including who the user is, where the user is located, what type of computing device the user is using, what rendering application is calling the DRM system, the date, the time, etc. In addition, the rules and requirements of the license 16 may limit the license 16 to a pre-determined number of plays, or pre-determined play time, for example.
The rules and requirements may be specified in the license 16 according to any appropriate language and syntax. For example, the language may simply specify attributes and values that must be satisfied (DATE must be later than X, e.g.), or may require the performance of functions according to a specified script (IF DATE greater than X, THEN DO . . . , e.g.).
Upon the license evaluator 20 determining that the license 16 is valid and that the user satisfies the rules and requirements therein, the digital content 12 can then be rendered. In particular, to render the content 12, the decryption key (KD) is obtained from the license 12 and is applied to (KD(CONTENT)) from the content package 13 to result in the actual content 12, and the actual content 12 is then in fact rendered.
In a DRM system 10, content 12 is packaged for use by a user by encrypting such content 12 and associating a license 16 having a set of rules with the content 12, whereby the content 12 can be rendered only in accordance with the rules in the license 16. Because the content 12 requires the license 16 for access thereto, then, the content 12 may be freely distributed. Significantly, the license 16 must somehow be bound either directly or indirectly to a computing device 14 on which the content 12 is to be rendered. Otherwise, the license 12 could potentially be copied to an infinite number of other devices 14 and rendered thereon, also.
Binding a license 16 to a device 14 is known or should be apparent to the relevant public and therefore need not be set forth herein in any detail. If directly bound, the license 16 may include an identifier of the device 14 therein and may require confirmation that the device 14 is indeed the device 14 identified in the license. If directly bound, the license 16 may include an encrypted decryption key decipherable only by a hardware or software construct on the device 14 (i.e., the trusted component 18), the construct may include the identifier of the device 14 therein, and the license 16 and/or construct may require confirmation that the device 14 is indeed the device 14 identified in the construct.
Typically, the license 16 is bound to a computing device 14 by way of a unique hardware identifier (HWID) incumbent in the device 14 and not easily transferable to any other device 14. Such HWID may be a physical HWID permanently inscribed into the device 14 and electronically obtainable from the device 14, or may be calculated from a number of values electronically present in the device 14, such as for example a serial number of a hard drive, a serial number of a memory, a serial number of a processor, etc. Calculating an HWID based on values incumbent in a device 14 is known or should be apparent to the relevant public and therefore need not be described herein in any detail. Significantly, trusted component 18 typically calculates the HWID from values present in the device 14, and such values are computer-readable and assumed to be trustworthy enough from a hardware point of view that a nefarious entity could not change or misrepresent the values in an effort to subvert the DRM system 10. That is, the hardware in the device 14 must be assumed to be trustworthy enough to prevent the changing or misrepresenting of the values.
However, it may be the case that it cannot in fact be assumed that the values in a device 14 are indeed trustworthy such that a HWID based on such values can be considered secure. That is, it may be the case that the hardware in the device 14 is not capable of being trusted to protect the values. For example, the hardware may not have any appropriate values, or the hardware may have appropriate values, but not in a computer-readable and secure form, or the hardware can be manipulated to give out an incorrect value, among other things. Such non-trustworthy hardware and values may especially be present in a relatively simple device 14, such as for example a portable music player or a portable data assistant. As may be appreciated, in such simple devices 14, there may be very little hardware to speak of, such hardware may not include computer-readable identifiers capable of acting as identifying values, the hardware may not be capable of communicating an identifier to the operating system, and/or the device 14 and the hardware thereof may not have the functionality necessary to divulge any such values, among other things. Of course, it may also be the case that other more complex devices 14 may also not have the trustworthy hardware and values necessary to impart a secure HWID to the device 14.
A need exists, then, for a method and mechanism to impart a secure HWID to a device 14 in the case where the hardware is not trusted to provide a secure HWID. Particularly, a need exists for a method and mechanism that allow a manufacturer of the device 14 to impart a secure HWID to a device 14 that can be obtained by the operating system of the device 14. Even more particular, a need exists for software on a device 14 as provided by the manufacturer that can be trusted to impart a secure HWID to the device 14 and to divulge such secure HWID to the operating system of such device 14, where the secure HWID cannot easily be changed or misrepresented by a nefarious entity.